To date, testing structural coverage has not been done directly. Normally a software simulation is used, adapted for running on a ‘host’ PC for example. On this host it is easy to find out the structural coverage of software. A first complete functional test of the software is also developed on this host. Moreover, a second functional test is developed adapted to the ‘target’ processor, which will receive the software during its normal operation. If the structural coverage is correct on the host and if both functional tests give the same results, it is deduced that the structural coverage is correct on the target.
Software is generally developed in a ‘high level’ language, like C for example, then translated into ‘machine’ language using only instructions directly comprehensible by the processor using the software. When the host processor is similar to that of the target, their machine languages are similar and the type of test disclosed earlier is reliable. But when the host and target processors have different architectures, their machine languages are also different. This difference leads to uncertainty regarding the deduction of structural coverage on the target.
Another solution consists in only performing tests on the target and adding a flag in each branch of the software. If, at the conclusion of the functional tests all the flags have been activated, this proves that all the branches of the software have been used and therefore that the structural coverage is correct. This solution has the drawback of increasing the processor's load factor and including instructions in the software, flags, useless to the operation of the software. These additional instructions degrade the software's reliability.